wafer.space Community - Frequency performance degradation using open-source PDK and tools

Hello all, I am an RTL designer with some knowledge on RTL GDSII flow. I am createding a chip with GP180 using LibreLane flow. Chip seems ready for manufacturing because LibreLane flow ended without errors. However, an ASIC created using this RTL is already in production, but it was created by an external company using my RTL with proprietary PDK and commercial EDA tools. I successfully run my proven in use test cases on the netlist with SDF coming from my open source flow, so I double-checked the outcome of the open source flow is correct. What concerned me s lot Is the speed degradation. Commercial ASIC is running at 75 MHz, my open source version is instead only 10 MHz capable at High temperature. So 7.5x degradation. I could expect something less performant but not likes this. I have seen part of the gap is due to primitives, open-source libraries is offering less primitives and the ones equivalent are up to 2x slower, but where is coming from the other part of the gap? Can be explained by less optimized tools? Do you have any similar experience where you can compare the same device realized with proprietary ASIC flow and open source flow? Thanks for any hint.

Hi @Simo6572, Was your previous chip created using the same GF180MCU process and a proprietary PDK, or did you use a different process? Note that the foundry-provided standard cell library in the open-source PDK uses the high-voltage transistors, which are slow. Tholin made a community-created standard cell library using the low-voltage transistors, which is much faster running at 3.3V. However, it hasn't been tested yet (the wafers are coming out of the fab this week).

1

@Simo6572 - I'm guessing you are likely using something like GF180IC or GF180BCDLite with something like 1v8 standard cells in the proprietary case while using 5v standard cells and the much cheaper GF180MCU in the open source case.

7:27 a.m.

@Simo6572 - You should also confirm what type of area / performance you have set things up at.

7:33 a.m.

@Simo6572 - There is some information about the various 180nm process technologies that GF has and where GF180MCU fits in regard to that @ https://wafer.space/gf180

7:34 a.m.

You could also easily give it a go on SKY130 and see how that compares.

It is also probably worth inspecting the output from Yosys of your RTL to see if it is doing something silly with your design.

also you need to tell librelane what you need in terms of performance and it'll try to get there. If you ask for 10 MHz it's not gonna try to pass timing in the slow corner at 75.

Chip in production is using different process ( anyway is 180nm process) with 3.3v IO and 1.8v Digital core. First GF180MCU flow completed was all 5V. I have just seen right now I can have 3.3v IO and 1.8V with GF180MCU so I am going to update and re run my flow to compare apples with apples

Moreover, switching to 1.8v core I found additional RAM sizes available that are fitting much better my needs

GF180mcu doesn't have any 1.8V device.

8:11 a.m.

You can run the standard cells at 1.8V but if you concern is speed, you won't like the resul.t

1

So the lib files I can see in the PDK are only about 3.3V standard cells supplied using 1.8V? In this case of course no sense doing that to improve speed and I will select 3.3V for both IO and Core

They are about 5.0V standard cells supplied using 1.8V.

1

there are 3v3 SCL but not from global foundries

8:25 a.m.

(on gf180mcuD, and as far as you don't have to sign an NDA to get them)

namibj

also you need to tell librelane what you need in terms of performance and it'll try to get there. If you ask for 10 MHz it's not gonna try to pass timing in the slow corner at 75.

Yes sure, I just relaxed step by step the constrains until I found a value not generating violations in the flow. Later on I will increase again step by step, but when I am sure nothing can be improved in the flow increasing frequency target means RTL changes, adding pipelines and so on

ok just checking

namibj

(on gf180mcuD, and as far as you don't have to sign an NDA to get them)

Thanks very useful info

Tim 'mithro' Ansell

@Simo6572 - I'm guessing you are likely using something like GF180IC or GF180BCDLite with something like 1v8 standard cells in the proprietary case while using 5v standard cells and the much cheaper GF180MCU in the open source case.

Assumption is almost correct. Commercial version is 1.8v core and 3.3v IO but a different 180nm proprietary process while open source version I prepared was 5v. I am preparing now a 3.3v version using gf180mcuD. Area of commercial version is about 4 mm2 while the first open source version was about 12 mm2 ( but part of the gap was surely due to the size of the ram module available in 5v rams, because to have the needed 1024x10 I used 4 modules). Anyway area is not the major concern until chip can stay in the largest die available for the shuttle. Moreover, 3.3 library provider different macro size for RAM that are better fitting my needs. Frequency is a different story, 10MHz is not enough, may be I can accept same relaxation and not exactly 75MHz, but I must be close to that or this open source chip will be never built because useless

Simo6572

Assumption is almost correct. Commercial version is 1.8v core and 3.3v IO but a different 180nm proprietary process while open source version I prepared was 5v. I am preparing now a 3.3v version using gf180mcuD. Area of commercial version is about 4 mm2 while the first open source version was about 12 mm2 ( but part of the gap was surely due to the size of the ram module available in 5v rams, because to have the needed 1024x10 I used 4 modules). Anyway area is not the major concern until chip can stay in the largest die available for the shuttle. Moreover, 3.3 library provider different macro size for RAM that are better fitting my needs. Frequency is a different story, 10MHz is not enough, may be I can accept same relaxation and not exactly 75MHz, but I must be close to that or this open source chip will be never built because useless

If your design is open source, then other people can probably also look into it.

My RTL is not open-source at all

as well as there are a lot of info I cannot share here about process and companies involved in the commercial version. At the moment this is an investigation to understand the feasibility to build in-house the first prototype of future ASICs as prove of concept ( that is currently done with FPGA based boards)

Simo6572

Assumption is almost correct. Commercial version is 1.8v core and 3.3v IO but a different 180nm proprietary process while open source version I prepared was 5v. I am preparing now a 3.3v version using gf180mcuD. Area of commercial version is about 4 mm2 while the first open source version was about 12 mm2 ( but part of the gap was surely due to the size of the ram module available in 5v rams, because to have the needed 1024x10 I used 4 modules). Anyway area is not the major concern until chip can stay in the largest die available for the shuttle. Moreover, 3.3 library provider different macro size for RAM that are better fitting my needs. Frequency is a different story, 10MHz is not enough, may be I can accept same relaxation and not exactly 75MHz, but I must be close to that or this open source chip will be never built because useless

You'll have to use the Avalon Semiconductors 3v3 SCL to have a good chance; there's an SRAM compiler giving much better density than the foundry open PDK macros offer by @Chips4Makers aka Staf Verhaegen . Note that the Avalon 3v3 SCL isn't currently too production-ready but that's mostly because there may be bugs left that haven't yet been caught through extracted SPICE behavioral sanity checking. For purposes of determining if you can do an RTL on a wafer.space slot at least near a target speed, it should suffice.

Note that you can also use Tim Edwards' SRAM macros, which are shrinked versions of the foundry ones.

1

10:53 a.m.

The project template allows you to choose the 3.3V SCL and SRAMs: https://github.com/wafer-space/gf180mcu-project-template#select-different-ip-libraries

1

I'm not saying the shrunk foundry SRAM are wrong

But Staf's periphery is far better at least at these sizes. And should be much more amenable to learning how to be 10bit wide.

Thanks to all but RAMs is not my major concern, I am wasting a bit of chip area but there is no timing violations related to menories trying to increase frequency. Switching from 5v to 3.3v max frequency increased by 50% and I am now at 15 MHz, of course still far from 75 MHz target. I guess I should start modifying my RTL. Of course is someone has some idea to further challenge the flow Is more than welcome. Thanks

Simo6572

Thanks to all but RAMs is not my major concern, I am wasting a bit of chip area but there is no timing violations related to menories trying to increase frequency. Switching from 5v to 3.3v max frequency increased by 50% and I am now at 15 MHz, of course still far from 75 MHz target. I guess I should start modifying my RTL. Of course is someone has some idea to further challenge the flow Is more than welcome. Thanks

If you haven't yet I'd suggest you try the recommended above (by mole99) way of using the Avalon SCL. But yeah, do expect to need RTL work. Assuming the librelane synth flow is mildly at a disadvantage to your tuned commercial flow, maybe try synthesizing for IHP SG13G2 or SG13CMOS5L (they are the same CMOS SCLs but the 5L has two less metal layers and lacks a bunch of fancy analog stuff to be like only 40% the cost to fab).

I believe there is still a huge amount of optimization and performance improvements that could be done in the open source tooling. The more people that start creating designs the more likely those things are to happen.

1

@Matt G. (Mobius) might have some thoughts or comments based on this work and paper @ https://arxiv.org/pdf/2606.04126 ?

12:42 a.m.

@Matt G. (Mobius) - It would be interesting to see the comparison between ORFS and LibreLane results for the same input RTL / PDK.

1

Tim 'mithro' Ansell

@Matt G. (Mobius) might have some thoughts or comments based on this work and paper @ https://arxiv.org/pdf/2606.04126 ?

There are some AI skills in HighTide for tips to improve PPA: https://github.com/VLSIDA/HighTide/blob/main/.claude%2Fskills%2Foptimize-ppa%2FSKILL.md As an aside though, clock skew is often the culprit. OR packs macros into one clock tree so if you have a bunch of SRAMs, for example, you could have a lot of skew between those and your logic. Check out how much skew affects your critical path... Similar to that, the default 20% of the period for input and output delays may not make sense in many cases.

HighTide/.claude/skills/optimize-ppa/SKILL.md at main · VLSIDA/Hig...

Contribute to VLSIDA/HighTide development by creating an account on GitHub.

Maybe interesting to know I did some comparisons between gf180mcu_as_sc_mcu7t3v3 standard cell library and the 1.8v library used by my chip in production at high temperature corner. On the same cells (for example 2nand 2nor inverter etc) GF is 50% - 80% slower. But more interesting , the commercial netlist include a lot of cells ( 4 6 8 input combinational gates and mux + inverter ) where I cannot find and equivalent in the netlist created by Yosys. This is probably generating part of the frequency gap because I can see on same netlist paths 1 cell of the commercial version replaced by 2-3-4 GF cells

@Simo6572 If you could compile a list of missing standard cells (sorted by usefulness), @Tholin might take a look at adding them to the SCL.

I’m just one person. I had to limit the scope of the project by taking a RISC approach. I synth’d a RISC-V SoC with the fab SCL and then only added cells that occured more than 20 or 30 times in the synth report to my to do list.

10:17 a.m.

I can add more cells to the SCL, but you’d be taping out with untested cells.

Yes sure I understand, I just posted what I think could be useful to know. I will create the list but again just for knowledge. Moreover, unfortunately I cannot share details of my project but it is not a RISC-V and not a processor at all

Tim has been very generous in giving me free shuttle slots to test my stuff, but if I add new cells now, those additions would be untested.

10:19 a.m.

And I will not be able to test SCL changes personally in this run. I intend to submit a fully analog layout to the free slot lottery. Expand the analog IP we have here.

10:21 a.m.

I could throw together something with my SCL in a half slot, but I believe submitting to the free lottery twice in one run is a bit rude, so I won’t do that.

We will very likely find some slot to test your new SCL additions in case you add new cells.

2

But I was thinking of going nuts with adding a bunch of combinatorial cells

10:24 a.m.

And then somebody can try taping out a SoC with it or something

2

I do hope to get (not alone) the muxed e-test in; it would have plans to incorporate coverage for as many SCL cells are are of questionable reliability or which have more than average need for e-test proof; it looks like there'd be between 50 and 200 DUTs of space by preliminary estimates.

1

Does SCL == Standard Cell Library

yeah